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OSPF-Based Layer 1 VPN Auto-Discovery 
Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
Abstract 


This document defines an Open Shortest Path First (OSPF) based Layer 
1 Virtual Private Network (L1VPN) auto-discovery mechanism. This 
mechanism enables provider edge (PE) devices using OSPF to 
dynamically learn about the existence of each other, and attributes 
of configured customer edge (CE) links and their associations with 
LIVPNs. This document builds on the L1VPN framework and requirements 
and provides a L1VPN basic mode auto-discovery mechanism. 
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1. Introduction 

1.1. Overview 
The framework for Layer 1 VPNs is described in [RFC4847]. Basic mode 
operation is further defined in [RFC5251]. The L1IVPN Basic Mode 


(L1VPN-BM) document [RFC5251] identifies the information that is 
necessary to map customer information (ports identifiers) to provider 
information (identifiers). It also states that this mapping 
information may be provided via provisioning or via an auto-discovery 
mechanism. This document provides such an auto-discovery mechanism 
using Open Shortest Path First (OSPF) version 2. Use of OSPF version 
3 and support for IPv6 are out of scope of this document and will be 
defined separately. 


Figure 1 shows the L1VPN basic service being supported using OSPF- 
based L1IVPN auto-discovery. This figure shows two PE routers 
interconnected over a GMPLS backbone. Each PE is attached to three 
CE devices belonging to three different LIVPN connections. In this 
network, OSPF is used to provide the VPN membership, port mapping, 
and related information required to support basic mode operation. 


PE PE 
4+--------- + 4+-------------- + 
+-------- + | +------ +| | +---------- + | +-------- + 
| vpN-a | | |vPN-A || | | ven-a | | | VPN-A | 
| CEl |--| [PIT || OSPF LSAs | | PIT | |-|  cE2 | 
+-------- + | | |<----------- >| | | +-------—- + 
#asses= +| Distribution| +---------- + 
| | | 
+-------- + | +------ +| | +---------- + | +-------- + 
| vPN-B | | |vPN-B || ------- | |  vpn-B | | | VPN-B | 
| CE1 |--| |PIT ||--( GMPLS )--| | PIT | |-| cE2 | 
+-------- + | | (Backbone) | | | AEE + 
4+------ +| — -------- 4+---------- + 
| | | | 
+-------- + | +----- + | | +---------- + | +-------- + 
| vpn-c | | |vpn-cl | | | vpn-c | | | vpeN-c | 
| CE1 |--| [PIT | | | | PIT | |-| CE2 | 
+-------- + | | | | +-------—- + 
4+----- + 4+---------- + 
4+--------- + 4+-------------- + 


Figure 1: OSPF Auto-Discovery for L1VPNs 
See [RFC5195] for a parallel LIVPN auto-discovery that uses BGP. The 


OSPF approach described in this document is particularly useful in 
networks where BGP is not typically used. 
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The approach used in this document to provide OSPF-based L1VPN auto- 
discovery uses a new type of Opaque Link State Advertisement (LSA) 
that is referred to as an L1IVPN LSA. The L1IVPN LSA carries 
information in TLV (type, length, value) structures. An L1VPN- 
specific TLV is defined below to propagate VPN membership and port 
information. This TLV is referred to as the LIVPN Info TLV. The 
LIVPN LSA may also carry Traffic Engineering (TE) TLVs; see [RFC3630] 
and [RFC4203]. 


1.2. Terminology 


The reader of this document should be familiar with the terms used in 
[RFC4847] and [RFC5251]. The reader of this document should also be 
familiar with [RFC2328], [RFC5250], and [RFC3630]. In particular, 
the following terms: 


L1IVPN - Layer 1 Virtual Private Network 


CE - Customer (edge) network element directly connected to the 
provider network (terminates one or more links to one or more 
PEs); it is also connected to one or more Cs and/or other CEs 


C - Customer network element that is not connected to the provider 
network but is connected to one or more other Cs and/or CEs 


PE - Provider (edge) network element directly connected to one or 
more customer networks (terminates one or more links to one or 
more CEs associated with the same or different LIVPNs); it is 
also connected to one or more Ps and/or other PEs 


P - Provider (core) network element that is not directly connected to 
any customer networks; P is connected to one or more other Ps 
and/or PEs 

LSA - OSPF link State Advertisement 


LSDB - Link State Database: a data structure supported by an IGP 
speaker 


PIT - Port Information Table 
CPI - Customer Port Identifier 


PPI - Provider Port Identifier 
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1.3. Conventions Used in This Document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 
2. L1IVPN LSA and Its TLVs 
This section defines the L1VPN LSA and its TLVs. 
Zols LIVPN LSA 
The format of a LIVPN LSA is as follows: 
0 1 2 3 


Od. 23% 4a 9. 16: 28529, (0! 1.2! 3 An 8 6 BG. OL. 2 3-49 16° 7-89 Oi 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 


| LS age | Options | LS Type | 
+-+-+-+-+-+-+-+-+-+-+-+-+- +++ 
Opaque Type | Opaque ID 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Advertising Router | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
LS Sequence Number | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
LS checksum | Length | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
LIVPN Info TLV 


| 
+ 
| 
+ 
| 
+ 
| 
+ 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
TE Link TLV | 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+—— + 


LS age 
As defined in [RFC2328]. 


Options 
As defined in [RFC2328]. 


LS Type 
This field MUST be set to 11, i.e., an Autonomous System (AS) 
scoped Opaque LSA [RFC5250]. 


Opaque Type 
The value of this field MUST be set to 5. 
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Opaque ID 
As defined in [RFC5250]. 


Advertising Router 
As defined in [RFC2328]. 


LS Sequence Number 
As defined in [RFC2328]. 


LS checksum 
As defined in [RFC2328]. 


Length 
As defined in [RFC2328]. 


L1IVPN Info TLV 
A single TLV, as defined in Section 3.2, MUST be present. If more 
than one LIVPN Info TLV is present, only the first TLV is 
processed and the others MUST be ignored on receipt. 


TE Link TLV 


A single TE Link TLV (as defined in [RFC3630] and [RFC4203]) MAY 
be included in a L1VPN LSA. 
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2.2. L1VPN INFO TLV 
The following TLV is introduced: 


Name: LIVPN IPv4 Info 
Type: 1 
Length: Variable 


0) 1 2 3 
01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| LIVPN TLV Type | L1IVPN TLV Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| L1IVPN Globally Unique Identifier 

Yai ee Ba igh ty Stan eat hata oh aa ind agen teat sel 
| PE TE Address | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Link Local Identifier | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| sa | 
| LIVPN Auto-Discovery Information 

+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| | Padding | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


L1VPN TLV Type 
The type of the TLV. 


TLV Length 
The length of the TLV in bytes, excluding the 4 bytes of the TLV 
header and, if present, the length of the Padding field. 


L1IVPN Globally Unique Identifier 
As defined in [RFC5251]. 


PE TE Address 
This field MUST carry an address that has been advertised by the 
LSA originator per [RFC3630] and is either the Router Address TLV 
or Local interface IP address link sub-TLV. It will typically 
carry the TE Router Address. 


Link Local Identifier 
This field is used to support unnumbered links. When an 
unnumbered PE TE link is represented, this field MUST contain a 
value advertised by the LSA originator per [RFC4203] in a Link 
Local/Remote Identifiers link sub-TLV. When a numbered link is 
represented, this field MUST be set to 0. 
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3 


3- 


LIVPN Auto-discovery information 
As defined in [RFC5251]. 


Padding 
A field of variable length and of sufficient size to ensure that 
the TLV is aligned on a 4-byte boundary. This field is only 
required when the L1VPN Auto-discovery information field is not 
4-byte aligned. This field MUST be less than 4 bytes long, and 
MUST NOT be present when the size of the LIVPN Auto-discovery 
information field is 4-byte aligned. 


L1IVPN LSA Advertising and Processing 


PEs advertise local <CPI, PPI> tuples in L1IVPN LSAs containing L1VPN 
Info TLVs. Each PE MUST originate a separate L1VPN LSA with AS 
flooding scope for each local CE-to-PE link. The LSA MUST be 
originated each time a PE restarts and every time there is a change 
in the PIT entry associated with a local CE-to-PE link. The LSA MUST 
include a single L1IVPN Info TLV and MAY include a single TE Link TLV 
as per [RFC3630] and [RFC4203]. The TE Link TLV carries TE 
attributes of the associated CE-to-PE link. Note that because CEs 
are outside of the provider TE domain, the attributes of CE-to-PE 
links are not advertised via normal OSPF-TE procedures as described 
in [RFC3630] and [RFC4203]. If more than one L1IVPN Info TLVs and/or 
TE Link TLVs are found in the LSA, the subsequent TLVs SHOULD be 
ignored by the receiving PEs. 


LIVPN LSAs are of AS-scope (LS type is set to 11) and therefore are 
flooded to all PEs within the AS according to [RFC5250]. Every time 
a PE receives a new, removed, or modified LIVPN LSA, the PE MUST 
check whether it maintains a PIT associated with the LIVPN specified 
in the L1VPN globally unique identifier field. If this is the case 
(the appropriate PIT will be found if one or more local CE-to-PE 
links that belong to the LIVPN are configured), the PE SHOULD add, 
remove, or modify the PIT entry associated with each of the 


advertised CE-to-PE links accordingly. (An implementation MAY choose 
to not remove or modify the PIT according to local policy or 
management directives.) Thus, in the normal steady-state case, all 


PES associated with a particular LIVPN will have identical local PITs 
for an L1VPN. 


1. Discussion and Example 


The L1IVPN auto-discovery mechanism described in this document does 

not prevent a PE from applying any local policy with respect to PIT 
management. An example of such a local policy would be the ability 
to configure permanent (static) PIT entries. Another example would 
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be the ability to ignore information carried in L1IVPN LSAs advertised 
by a specific TE. 


The reason why it is required that the value specified in the PE TE 
Address field of the LIVPN Info TLV matches a valid PE TE Router ID 
or numbered TE Link ID is to ensure that CEs attached to this PE can 
be resolved to the PE as it is known to the Traffic Engineering 
Database (TED) and hence TE paths toward the CEs across the provider 
domain can be computed. 


Let us consider the example presented in Figure 2. 


CE11 CE13 
pate paeron PaSses= PE2 
chs PES 
a 


Figure 2: Single Area Configuration 


Let us assume that PE1l is connected to CE11 and CE15 in L1VPN1 and to 
CE22 in LIVPN2; PE2 is connected to CE13 in L1VPN1; PE3 is connected 
to CE24 in LIVPN2. In this configuration PE1 manages two PITs: PIT1 
for L1VPN1 and PIT2 for L1IVPN2; PE2 manages only PIT1; and PE3 
manages only PIT2. PE1 originates three LIVPN LSAs, each containing 
a LIVPN Info TLV advertising links PE1-CE11, PE1-CE22, and PE1-CE15, 
respectively. PE2 originates a single L1IVPN LSA for link PE2-CE13, 
and PE3 originates a single L1IVPN LSA for link PE3-CE24. In steady 
state, the PIT1 on PE1 and PE3 will contain information on links 
PE1-CE11, PE1-CE15, and PE2-CE13; PIT2 on PE1 and PE2 will contain 
entries for links PE1-CE22 and PE3-CE24. Thus, all PEs will learn 
about all remote PE-to-CE links for all L1VPNs supported by PEs. 


Note that P in this configuration does not have links connecting it 
to any LIVPNs. It neither originates LIVPN LSAs nor maintains any 
PITs. However, it does participate in the flooding of all of the 
L1IVPN LSAs and hence maintains the LSAs in its LSDB. This is a cause 
for scalability concerns and could prove to be problematic in large 
networks. 


4. Backward Compatibility 
Neither the TLV nor the LSA introduced in this document present any 


interoperability issues. Per [RFC5250], OSPF speakers that do not 
support the L1VPN auto-discovery application (Ps for example) just 
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participate in the LIVPN LSAs flooding process but should ignore the 
LSAs contents. 


5. Security Considerations 


The approach presented in this document describes how PEs dynamically 
learn L1IVPN-specific information. Mechanisms to deliver the VPN 
membership information to CEs are explicitly out of scope of this 
document. Therefore, the security issues raised in this document are 
limited to within the OSPF domain. 


This defined approach reuses mechanisms defined in [RFC2328] and 
[RFC5250]. Therefore, the same security approaches and 
considerations apply to this approach. OSPF provides several 
security mechanisms that can be applied. Specifically, OSPF supports 
multiple types of authentication, limits the frequency of LSA 
origination and acceptance, and provides techniques to avoid and 
limit impact database overflow. In cases where end-to-end 
authentication is desired, OSPF’s neighbor-to-neighbor authentication 
approach can be augmented with an experimental extension to OSPF; see 
[RFC2154], which supports the signing and authentication of LSAs. 


6. IANA Considerations 


This document requests the assignment of an OSPF Opaque LSA type. 
IANA has made the assignment in the form: 


Value Opaque Type Reference 
5 LIVPN LSA [RFC5252] 
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